Hey Scott,
I wish I had a sample that did exactly what you want, but I don't. As a beginning Java developer, I would say that I think your are going about it the right way, but perhaps you need to simplify your goals along the way.
Before I get into that, I'd suggest that you look at the tools from InstantTech (
http://www.intant-tech.com ) and Cobra Technologies (
http://www.cobratech.com ). The companies are offering tools and pre-built apps to make your task a bit easier. If you goal is to get a bot available, I might go for one of the tools than the development path.
Some suggestions....
1. Try not to get into the text parsing/recognition issue right away. For your intial stages, build it with the assumption is going to type in a single command or verb and search the DB for a document that matches. For instance, you might limit the queries to something like "whatis x" ( roughly how our acronym bot works). You parse off the command and just look for "x".
2. I have a sample, which I will try to send you ( I'll also try to post to the Sandbox), that stores a list of Acronyms in a Notes DB and retrieves them from a view. To retrieve from the view I use the getDocumentByKey method of NotesView, rather than doing a FT search. Once you have the basics, you can expand the concept to FT Search.
3. If you are new to Notes, you might find starting with the assumption that the DB is local. Ideally you want remote access, but for initial prototype work with the DB on the same machine as the code is running.
4. If you are familar with Notes, you could make the DB accessible via HTTP and use a Lotuscript agent to create the search mechanisms and output the data in XML ( better yet, build it as a web service ). This might simplify the Java code in your bot, as you'll be calling the search and content retrieval functions as services. There a loads of samples for building these types of agents and Java code for calling web services that you can copy from.
Those are just some thoughts from the top of my head. I hope others will share some additional suggestions.
Rooney
BTW...Part Two of our article should be published in March ( I hope), but it's focus is on having the application initiate the conversation and not the items you list above.